Temporal Speciication Veriication via Causal Reasoning

We present a technique for verifying the timing speci cations of the interfaces between digital systems. The veri cation process takes as input the timing protocols of each component as well as the connectivity between the components. The technique proceeds in three steps. First, a graph is built, which describes the causal relationships of events which can occur in the complete system. Second, a set of requirements (from the speci cations) are used to identify pairs of events which must (or must not) happen with a particular temporal relationship. Third, for each such requirement, the sequences of events which might lead to such a requirement violation are identi ed and traced to determine if the requirement is violated or satis ed. The technique supports protocols with time ranges on transitions, and conditional events based on dynamic sensitivity to system state. Introduction: The Veri cation Problem Attempts to reason about digital systems have been ongoing for many years [1{3]. Various methods for modeling time delays have been proposed and formal veri cation methods investigated [4{7]. Methods based on simulation have also been used to verify circuits[8,9]. Recent work has taken a symbolic approach to attempt to reason about circuits [10,11] as well as our previous work [12,13] which investigated a simpler veri cation technique, upon which this work is based. As in our previous work, our goal is to provide a technique for automatically verifying the temporal protocols used in the interfaces between digital systems. The technique uses three kinds of information about the system it is verifying. First, are the external actions of each of the component sub-systems, or modules. These are (generally) taken by the module in response to external events from other modules. Second, are the temporal constraints, or requirements, which each module places on its environment in order for it to operate correctly. Taken together, these comprise the temporal protocols of the system. Third, are the actual interconnections between the inputs and outputs of the modules in the system. Given this information the technique is used to verify that no sequence of actions (events) taken by the modules will violate any of the requirements speci ed for the system. In this work, the veri cation process is dependent on an underlying assumption that the system is completely speci ed (i.e., all information regarding the system is known). This assumption is necessary and su cient for the veri cation process to occur. It is necessary since permitting the possibility of unknown information in the system a ecting system operation results in incorrect reasoning. An incompletely speci ed system is one where not all information is known about how all control signals in the system interact. Taken to an extreme, this implies that signals may change values in an unpredictable manner, at any time, precluding the possibility of verifying correct behavior. The assumption that the system is fully speci ed is su cient for veri cation. If all information is known about the system, then, within the scope of the model used, no unanticipated action can occur in the system which could a ect the veri cation process. The veri cation methodology analyzes relationships between events on signals.1 A signal is a physical entity (e.g., a wire) or a virtual identi er (e.g., a variable) which can have two values, high and low. Restricting signals to two values can be done without loss of generality in the veri cation 1This section provides an overview of the terminology which will be used; formal de nitions appear in [12,14]. 1 process since we can use variables to represent wires with arbitrary values. The transition of a signal from high to low is called a falling event and the transition from low to high is a rising event. Although the system supports time ranges for when events occur, the events themselves occur instantaneously. The syntax A/ (A") and A\ (A#) denotes rising and falling events on signal A respectively. Within this framework, the two kinds of statements which a designer can use to describe the interface protocols are causality statements and requirement statements. These are analogous to \recommended conditions" and \switching characteristics" in published data sheets. They are also similar to Seitz's functional relations and domain relations [15]. These statements describe relationships between events. The rst type of statement describes causality: \e1[when w1] ! e2[when w2] (A;B)." In this expression: e1 and e2 are events (such as rising or falling); w1 and w2 are boolean expressions called enabling expressions; and (A;B) is a min/max time range. The meaning of this expression is that if event e1 happens when w1 is true then event e2 will occur provided w2 is true within the time range de ned by A and B. The second kind of statement expresses the constraints that a device puts on the rest of the environment in order for it to operate correctly. This is a requirement on the temporal relationships of signals to ensure correct operation of the device. During veri cation, a requirement is checked by comparing the temporal relationship between its two events and determining if the required timing is violated. There are two types of requirements in the system: positive requirements and negative requirements. The positive requirement of \e1[when w1] j e2[when w2] (A;B)" means that event e2 and event e1 are related such that event e2 must occur no less than A and no more than B after event e1. If the enabling expressions w1 or w2 are present, then w1 or w2 must be true when e1 or e2 occurs for the requirement to be veri ed, otherwise the requirement is ignored. The symmetric case to the positive requirement, called the negative requirement, is also supported. The negative requirement is expressed as \e1[when w1] <> e2[when w2](A;B)" and means that event e2 and event e1 are related such that event e2 must not occur within the range A t B after event e1. If the enabling expressions w1 or w2 are present, then w1 or w2 must be true when e1 or e2 occurs for the requirement to be veri ed, otherwise the requirement is ignored. The enabling expressions on all three types of statements are conjunctions of signal values and negated signal values. For statements with enabling expressions, the values of signals in the system must be consistent with the expression in order for the event to be active. The tracing of the causalities to determine the relative time of events is complicated by two properties: time ranges on events and system state a ecting enabling expressions. The handling of these properties correctly is both di cult and necessary for the veri cation of non-trivial systems. The remainder of this paper provides a description of the veri cation process. First, the analysis procedure based on graph construction and traversal is presented. Next, the search process and system history creation is described. Finally, the veri cation process using a complete system history is discussed. 2 Event Graph Construction and Analysis Given a set of causalities which de ne the system to be veri ed, a causal event graph is built where the nodes of the graph are the events and the directed arcs in the graph are the causal relationships. Each arc is annotated with the relative time range, , and the two enabling expressions, w1 and w2. The requirements are not kept explicitly in the graph but are used to guide the search process. Each requirement speci es a timing relationship which must be maintained between two events, e1 and e2, known as the requirement nodes or events. If these events ever happen, then they appear in some causality and therefore the events are represented as nodes in the event graph. Once the event graph is built, each requirement can be veri ed by tracing paths through the graph which lead to the two events constrained by the requirement. To verify the timing relationship, a common time reference must be established between e1 and e2. This is accomplished by nding all nodes in the graph which are ancestors to the requirement nodes. Ancestors of the requirement nodes are all of the nodes in the graph which can cause the requirement event through one or multiple causalities. All events in the graph which are ancestors to both requirement events are called the ParentSet. Only nodes in the ParentSet can provide a common time reference between e1 and e2 and in a fully speci ed system, only nodes in the ParentSet can possibly cause a con ict. For each node e 2 ParentSet, the graph is analyzed to determine if a single occurrence of e, the common reference event, can cause both e1 and e2 in the system. Although e may cause e1 or e2 in isolation, it may not be possible for e to result in both e1 and e2. The paths in the graph from e to e1 and from e to e2 may be mutually exclusive due to the enabling expressions associated with each causality along the path. The determination of possible paths through the graph is discussed in the next section. Creating System Histories To verify a requirement, an analysis must be performed to determine if there is a path from e 2 ParentSet to each of the requirement nodes, e1 and e2. If a path can occur from e to one of the requirement nodes, then that path is said to be active. Only if there are two active paths, one from e to each requirement node, do e1 and e2 have a common time reference in e. This is the only case where the relative time between e1 and e2 needs to be checked for requirement violation. If both paths are not active, then it is not possible for a single occurrence of e to generate both e1 and e2 and therefore it cannot cause a violation. The forward analysis in time from a single event transition, e, is referred to as a system history, H. A system history is a particular set of paths (or tree) through the graph representing a distinct evolution of events based on a subset of all possible signal interactions. There are many possible system histories which can be constructed from the occurrence of e. The histories may appear identical before they \branch" into unique sequences of transitions. Some histories may contain e1 and e2 and other histories may not. The size of the search space of all possible system histories from a single reference event e can be extremely large for even a small system. The nature of this problem leads to a tree-like search space which has many alternatives or branch points. The reduction of the size of the search space by 3 minimizing the number of branch points is key to keeping the problem within a manageable scope. This reduction is performed by: using a directed search based on the requirements, performing reasoning with symbolic time ranges, and minimizing the bifurcation by splitting only when needed. A system history consists of two sets of events: events which have been fully traced are kept in P and their descendants which have not yet been fully traced are kept in F . System histories are constructed as follows. As each event is moved from F to P, all causalities which have that event as their left-hand side (LHS) and whose conditional is true have their right-hand side (RHS) event added to F . As events are traced through the graph, histories are built up by moving events incrementally from F to P . Causalities A/ -> B/ (10,20) B/ -> C/(15,20) P F t = 5 hA"; 0; 0i 0 5 ABC hB"; 10; 20i t = 25 hA"; 0; 0i hB"; 10; 20i 0 5 10152025 ABC hC"; 25; 40i t = 45 hA"; 0; 0i hB"; 10; 20i hC"; 25; 40i 0 5 1015202530354045 ABC ; Figure 1: Illustration of system history creation Figure 1 shows an example of the creation of a system history. The system consists of two causalities and an event, A" which occurs at t = 0. The gure illustrates how events are inserted into F and then moved from F to P as the system history is constructed. At a given time, the combination of P and F is a system history which uniquely describes the state of the system. To meet the goal of veri cation, we must construct all of the possible complete system histories which may cause a requirement violation. A complete system history is a system history which has reached one of two termination conditions: either F is empty (as in Figure 1), or F is identical to a previous instance of F for that history. In the second case, the system history has cycled and no new states will be explored by continuing to move events from F to P . The construction of system histories is complicated by the interaction of enabling expressions of the causalities. The enabling expressions can cause a bifurcation or split in the system history search process and therefore result in multiple system histories. Figure 2 illustrates the causality A/ when C -> B/ (10,10) knowing that A/ occurs from 0 t 20, C falls at t = 5 and C rises at t = 15. In the analysis of this causality, there are three cases to consider producing a three-way branch in the system history. The rst case is if A rises in the range 0 t 5. In this case, A will cause B to rise as shown by B0. The second case is if A rises in 4 0 5 10 15 20 25 30 A B0 B00 C Figure 2: A/ when C -> B/ (10,10) hA"; 0; 20i 2 FA hA"; 5; 20i 2 FA hA"; 15; 20i 2 FA hA"; 0; 5i 2 PA hA"; 5; 20i 2 FA hA"; 5; 15i 2 PA hA"; 15; 20i 2 FA hA"; 15; 20i 2 PA hA"; 0; 5i 2 PA hA"; 5; 15i 2 PA Ha(t = 0) Hd(t = 0) Hg(t = 0) A rises (0;5) ( ) A does not rise (0;5)+ * Hb(t = 5) A rises (5;15) ( ) A does not rise (5;15)+ * He(t = 15) Hh(t = 25) Hc(t = 10) Hf (t = 20) Figure 3: Events on signal A during the construction of three system histories the range 5 t 15. In this case, the causality is not triggered and A/ does not cause B to rise. The third case is if A rises in the range 15 t 20. In this case, A will cause B to rise as shown by B00. This simple example illustrates that although A rises in a simple time range, the next step in the system history must be considered by a case analysis of the three possibilities and denotes a system history branch point. The creation of the three system histories hinges on the interaction of A/ with signal C. Figure 3 illustrates how the A transition is moved from F to P incrementally. When an interaction with C occurs which requires a split in the system history, time is \rolled back" and the current A/ transition is bifurcated. As such, the history Hb results in a split where A/ is split into the region from 0 t 5 and 5 t 20; further processing causes the He to be split. The three complete histories where A/ occurs in 0 t 5, 5 t 15, and 5 t 20 can be seen in Figures 4, 5, and 6 respectively. These gures also identify the events as they are incrementally transferred from F to P. A troublesome problem for some systems is the correct handling of reconvergent paths. In our technique, reconvergent paths are handled during the construction of P . We enforce the restriction that the time ranges of events for a given signal on P cannot overlap. This restriction is maintained through the bifurcation of system histories whenever the time ranges of two events on the same signal in P would overlap when moving an event from F to P . 5 Causality A/ when C -> B/ (10,10) P F Ha(t = 0) 0 A BC hA"; 0; 20i hC#; 5; 5i hC"; 15; 15i Hb(t = 5) hA"; 0; 5i hC#; 5; 5i 0 5 ABC hA"; 5; 20i hB"; 10; 15i hC"; 15; 15i Hc(t = 10) hA"; 0; 5i hC#; 5; 5i 0 5 10 ABC hB"; 10; 15i hC"; 15; 15i Hend(t = 20) hA"; 0; 5i hB"; 10; 15i hC#; 5; 5i hC"; 15; 15i 0 5 101520 ABC ; Figure 4: Complete history resulting if A transitions in 0 t 5 An example of a reconvergent path is shown in Figure 7. For this example, the \naive" waveform is what a designer might sketch where A0 and A00 are both transitions of signal A which overlap in time. Extending the concepts from the previous example with the added condition that transitions on the same signal cannot overlap results in three individual complete histories, Hx, Hy , and Hz . These histories result from two bifurcations applied to the original transition A/. Thus, the reconvergent path for signal A is split as needed and each case is fully traced. System History Veri cation Once a complete system history is built, the timing relationship between events can be evaluated to determine if the particular requirement being tested is satis ed or violated. Since the requirement being veri ed speci es two events, e1 and e2 with their associated enabling expressions w1 and w2, then the veri cation process compares all combinations of e1 when w1 and e2 when w2 present in the complete system history. Each comparison directly yields whether this requirement has been satis ed or violated. The entire system has been veri ed once each complete system history generated for each requirement has been tested. 6 Causality A/ when C -> B/ (10,10) P F Hd(t = 0) 0 A BC hA"; 5; 20i hC#; 5; 5i hC"; 15; 15i He(t = 15) hA"; 5; 15i hC#; 5; 5i hC"; 15; 15i 0 5 1015 ABC hA"; 15; 20i hB"; 15; 25i Hf (t = 20) hA"; 5; 15i hC#; 5; 5i hC"; 15; 15i 0 5 101520 ABC ; Figure 5: Complete history resulting if A transitions in 5 t 15 Conclusion This paper has presented a technique for a temporal veri cation system for digital interfaces. The veri cation process searches the space of possible system timing behaviors, looking for timing violations. This search process is guided by the knowledge of the timing relationships that must not be violated to ensure proper operation. This reduces the complexity of the search problem with the tradeo that the veri cation process performs only safety tests and not liveness tests. The advantages of this approach are that it does not di erentiate between synchronous and asynchronous systems and works equally well for both. In addition, the system does not need additional \hints", user intervention, or require speci c design styles. Finally, the technique supports protocols with time ranges on transitions, and conditional events based on dynamic sensitivity to system state. 7 CausalityA/ when C -> B/ (10,10)PFHg(t = 0)0ABChA"; 15; 20ihC#; 5; 5ihC"; 15; 15iHh(t = 25)hA"; 15; 20ihC#; 5; 5ihC"; 15; 15i0 5 10152025ABChB"; 25; 30iHend(t = 35)hA"; 15; 20ihB"; 25; 30ihC#; 5; 5ihC"; 15; 15i0 5 101520253035ABC;Figure 6: Complete history resulting if A transitions in 15 t 20\Naive" Waveform0 5 10152025303540A0BA00Hx0 5 10152025303540A0BA00Hy0 5 10152025303540A0BA00Hz0 5 10152025303540A0BA00Figure 7: Reconvergent Path with causalities A/ -> B/ (5,5) and B/ -> A\(5,5)8 References[1] Thomas M. McWilliams, \Veri cation of Timing Constraints on Large Digital Systems," Proc.17th Design Automation Conference (June, 1980).[2] Robert B. Hitchcock, Sr., \Timing Veri cation and the Timing Analysis Program," Proc. 19thDesign Automation Conference (June, 1982).[3] John J. Wallace, \On Automatic Veri cation of SLIDE Descriptions," Design Research Center,Carnegie-Mellon University, DRC-01-2-80, Pittsburgh, PA, Aug., 1979.[4] David E. Wallace, \Abstract Timing Veri cation for Synchronous Digital Systems," ComputerScience Division, Univ. of Calif. at Berkeley, UCB/CSD 88/425, Berkeley, CA, June 27, 1988.[5] David L. Dill, \Trace Theory for Automatic Hierarchical Veri cation of Speed-IndependentCircuits," Dept. of Computer Science, Carnegie-Mellon University, CMU-CS-88-119, Pittsburgh,PA, Feb., 1988.[6] M. Browne, E. Clarke, D. Dill & B. Mishra, \Automatic Veri cation of Sequential CircuitsUsing Temporal Logic," Dept. of Computer Science, Carnegie-Mellon University, CMU-CS-85-100, Pittsburgh, PA, Dec., 1984.[7] Patrick C. McGeer & Robert K. Brayton, \Timing Analysis in Precharge / Unate Networks,"Proc. 27th Design Automation Conference (June, 1990).[8] Tod Amon & Gaetano Borriello, \On the Speci cation of Timing Behavior," Proceedings ofthe 1990 ACM International Workshop on Timing Issues in the Speci cation and Synthesis ofDigital Systems (TAU '90), New York, NY, SIGDA(Aug., 1990).[9] Dimitrie Doukas & Andrea S. LaPaugh, \CLOVER: A Timing Constraints Veri cation System,"Proceedings of the 1990 ACM International Workshop on Timing Issues in the Speci cation andSynthesis of Digital Systems (TAU '90), New York, NY, SIGDA(Aug., 1990).[10] F. Mavaddat & T. Gahlinger, \On Deducing Tight Bounds from Partial Timing Speci cations,"Proceedings of the 1990 ACM International Workshop on Timing Issues in the Speci cation andSynthesis of Digital Systems (TAU '90), New York, NY, SIGDA(Aug., 1990).[11] Michael C. McFarland, \CPA: Giving an Account of Timed Systme Behavior," Proceedings ofthe 1990 ACM International Workshop on Timing Issues in the Speci cation and Synthesis ofDigital Systems (TAU '90), New York, NY, SIGDA(Aug., 1990).[12] Alan R. Martello & Steven P. Levitan, \Causal Timing Veri cation," Proceedings of the 1990ACM International Workshop on Timing Issues in the Speci cation and Synthesis of DigitalSystems (TAU '90), New York, NY, SIGDA (Aug., 1990).9 [13] Alan R. Martello, Steven P. Levitan & Donald M. Chiarulli, \Timing Veri cation Using HDTV,"Proc. 27th Design Automation Conference (June, 1990).[14] Alan R. Martello, \Temporal Speci cation Veri cation," Dept. of Elect. Eng., University ofPittsburgh, PhD. Dissertation (in preparation).[15] Charles L. Seitz, \System Timing," in Introduction to VLSI Systems, Carver Mead & LynnConway, eds., Addison Wesley, Reading, MA, 1980, 245.10